Do we need to add this accessor?

Probably not, but had added it to be consistent with dsn and should_send_default_pii. While I can kind of see why we have something for should_send_default_pii, I'm not sure why we have dsn in the first place - any context?

There's also client options for which we do not provide accessors. We can always add the accessor later on if there's popular demand, but IMO it'd be good to avoid public API bloat.
If it's convenient for us in the integrations we can also keep a private _data_collection() accessor.

Sounds good, will remove

Do we need to add this accessor?

We might not depending on our convo in the other comment that's related.

This was added for consistency with dsn and should_send_default_pii, but otherwise I don't think we need this.

Spotlight frame flags disagree

Medium Severity

In DSN-less Spotlight mode, re-derived data_collection uses include_local_variables is not False (and the same for include_source_context), while _resolve_data_collection treats those options with bool(value) when they are not None. Falsy non-boolean values such as 0 resolve to disabled frame settings initially but become enabled after the Spotlight override.

 

^{Reviewed by Cursor Bugbot for commit 15c21c0. Configure here.}

Unpickled client missing data_collection

Low Severity

_Client.__setstate__ restores options from pickled state and calls _init_impl without ensuring a resolved data_collection entry exists. Clients pickled before this option was added have no data_collection key, so DSN-less Spotlight setup or the new data_collection property can raise KeyError.

 

^{Reviewed by Cursor Bugbot for commit 15c21c0. Configure here.}

String http_bodies becomes char list

Medium Severity

In _resolve_explicit, a user-provided http_bodies value is passed through list(http_bodies) whenever it is not None. A string is iterable, so a mistaken string body type becomes a list of single-character strings instead of rejecting the value or treating it as one body type.

 

^{Reviewed by Cursor Bugbot for commit 15c21c0. Configure here.}

Bug: The _http_headers_from_value function silently misinterprets string inputs, leading to an incorrect configuration that is the opposite of the intended effect.
_{Severity: MEDIUM}

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: sentry_sdk/data_collection.py#L182-L191

Potential issue: The function `_http_headers_from_value` in
`sentry_sdk/data_collection.py` incorrectly processes non-dictionary inputs. If a truthy
string like `"off"` is passed for the `http_headers` option, the code performs a
substring check (`"request" in val`) instead of a dictionary key lookup. This check
evaluates to false, causing the function to return a default value that is the opposite
of the user's likely intent. Unlike other similar functions in the file which would
raise an `AttributeError` on invalid input, this function fails silently and produces an
incorrect configuration, potentially leading to unintended data collection behavior.

get_data_collection() raises AttributeError — no .data_collection attribute exists on any client class

get_data_collection() in scope.py accesses Scope.get_client().data_collection, but no data_collection property or attribute is defined on BaseClient, NonRecordingClient, or _Client; the resolved value lives at self.options["data_collection"]. There is no __getattr__ fallback, so any call to this helper will raise AttributeError. The helper is currently unused (the PR notes the option is not yet hooked up), so this is a latent bug that will surface on first use.

_{Identified by Warden code-review · 3TS-36F}